ADFA-5487: Make the editor's memory chart a carousel of metric displays - #1784

Three defects raised in review of ADFA-5487/5489, all in the same few
lines and all present in both watchers.

stopWatching() could not stop the sampler. The loop was launched with
`launch(context = SupervisorJob() + dispatcher)`, which gives the
coroutine its own parent job, so the watcher's scope could not cancel
it: it ran on until it next observed the `watching` flag, and it spends
almost all of its time asleep in `delay(updateInterval)`. Stop and start
inside that window and the old loop woke up, saw the flag set again, and
carried on beside the new one -- two samplers writing history and
notifying the chart. The window is as wide as the interval, which
ADFA-5486 made configurable up to sixty seconds. The job is now stored
and cancelled.

An exception ended sampling permanently. A throw anywhere in the body
killed the coroutine while `watching` stayed true, so every later
startWatching() was refused as "already watching" and the chart silently
stopped updating for the rest of the session. A misbehaving listener was
enough. The body is guarded now: a sample is worth losing, the loop is
not. CancellationException is rethrown so cancellation still works.

The dispatcher was never closed. `newSingleThreadContext` holds a thread
until closed, and nothing closed it. close() is separate from
stopWatching() because the watcher is stopped and restarted across the
editor's lifecycle; only the terminal teardown should give up the
thread. MetricsViewModel.onCleared calls it.

startWatching() also uses compareAndSet rather than a check followed by
a set, so two callers cannot both pass the guard.

Tests: 5 new lifecycle tests. Verified they fail without the fix, though
the first one fails by hanging rather than by asserting -- with the loop
unstoppable, runTest never drains the scheduler. That is the bug seen
from the inside, and it is why each test now closes its watcher.

Verified on a Pixel 6 Pro (arm64), v8 debug: chart samples continuously
across a background/foreground cycle, no crashes, nothing logged from
the new failure guard. 70 tests green across app ui/utils.

Addresses CodeRabbit findings on #1784.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* style: spotless reformat, no functional change

Enroll SwipeRevealLayout.kt in the file-level Spotless ratchet ahead of
the ADFA-5487 functional change, so the whole-file reindent to tabs is
not reviewer noise in a behavioral commit.

ktlint changes only: import ordering, parameter list wrapping, and
`return x` to expression-body conversions.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix: stop SwipeRevealLayout's right drag helper capturing every child

RightDragCallback.tryCaptureView returned an unconditional `true`, with
the intended check commented out as `// child.id == R.id.right_drawer_sidebar`
-- an id that exists nowhere in the project. There is no right drawer in
activity_editor.xml, so the helper had no legitimate target but captured
whichever child sat under a horizontal drag and offset it sideways.

Two consequences, both fixed by never capturing:

- onViewPositionChanged pushed that horizontal travel straight to
  dragListener.onDragProgress, bypassing the layout's own onDragProgress.
  BaseEditorActivity.onSwipeRevealDragProgress then animated the content
  card's corner interpolation and top padding as if the vertical reveal
  were being dragged.
- onInterceptTouchEvent returns `isLeft || isRight || isVertical`, so the
  layout stole horizontal gestures from its children. A horizontally
  scrolling child raced this helper across the same ViewConfiguration
  touch slop, making the outcome nondeterministic. ADFA-5487 puts a
  ViewPager2 carousel in exactly that position, which is how this
  surfaced.

No edge tracking is configured, so with capture refused the helper is
inert. The callback is left in place as the attachment point for a right
drawer, should one ever be added.

Verified: :app:compileV8DebugKotlin.

ADFA-5487

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* refactor: extract MemoryUsageChartRenderer, render from watcher history

BaseEditorActivity drove the memory chart by reaching into
binding.memUsageView.chart from six sites and mutating entry.y against a
pidToDatasetIdxMap that only resetMemUsageChart() populated. That works
only while exactly one chart view exists for the activity's lifetime.
ADFA-5487 makes the chart one page of a carousel, where the view can be
unbound, recycled, or created long after watching began.

MemoryUsageChartRenderer owns the chart wiring instead and holds no
sample state: MemoryUsageWatcher already keeps each process's
usageHistory ring buffer, so the renderer can rebuild a complete chart
from getMemoryUsages() at any time. attach/detach are independent of the
data.

Two behaviour changes, both deliberate:

- attach() renders the full existing history. resetMemUsageChart() used
  to seed every entry with 0f and wait a tick for real values, which a
  carousel page bound mid-session would show as a flat line.
- onUsagesChanged() rebuilds when the incoming processes no longer match
  the chart's datasets, instead of logging "No dataset found for
  process" and dropping that process's samples. This was already
  reachable without a carousel: ProjectHandlerActivity watches the
  Gradle Tooling process and then calls resetMemUsageChart(), so any
  sample arriving between those two lines was discarded.

The once-a-second path still mutates the existing Entry objects in place
and allocates nothing; the rebuild is the exception, not the rule. The
renderer relies on ChartData.getDataSetByIndex returning null for an
out-of-range index, which the shipped AndroidChart 3.1.0.21 bytecode
confirms (null for index < 0 or >= size) -- the same guard the previous
code depended on.

Sites swept: all six chart call sites in BaseEditorActivity, both
resetMemUsageChart() callers in ProjectHandlerActivity (unchanged, the
method keeps its signature), and the now-dead
pidToDatasetIdxMap/editorSurfaceContainerBackground members and their
imports. No other module referenced either.

Tests: 5 new Robolectric tests in MemoryUsageChartRendererTest. Verified
they fail without the fix -- reverting the two behaviour changes fails
"attach renders the complete existing history", "attach after detach
renders the history into the new chart" (all-zero entries) and
"onUsagesChanged rebuilds when a process starts being watched"
(dataSetCount stays 1), each for the reason it is named for. The
in-place-update test passes either way by design, since that path is
unchanged.

Verified: :app:compileV8DebugKotlin, :app:testV8DebugUnitTest
(MemoryUsageChartRendererTest, 5/5). No UI change, so no font-scale
check yet; that lands with the carousel.

ADFA-5487

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: make the editor's memory chart a carousel of metric displays

The chart at the top of the editor (revealed by dragging the app bar
down) is now a ViewPager2 carousel. Page 1 is the memory chart, still
the default; page 2 is the Code On The Go brand mark, a placeholder
until there is a real second metric.

MetricsCarouselAdapter takes its page list as a constructor argument, so
the follow-up tickets (a TrafficStats network chart, and plugin-
contributed displays) add pages rather than change this class. The chart
page attaches MemoryUsageChartRenderer on bind and detaches on recycle;
because the renderer rebuilds from MemoryUsageWatcher's history, swiping
away and back shows the full 30-sample series rather than a flat line.

Layout notes:

- layout_mem_usage.xml stays a single view. SwipeRevealLayout asserts
  childCount == 2 and indexes its children positionally, so the include
  cannot gain a sibling; the pager and indicator live inside it.
- The status-bar inset now applies to the pager rather than the chart,
  so MemoryUsageChartRenderer.setTopMargin (a shim from the previous
  commit, when the activity owned the only chart) is gone. It gains
  detachIfAttached, which a recycling container needs: RecyclerView can
  bind a replacement view before recycling the one it replaced, and an
  unconditional detach would then drop the new chart.
- editor_mem_usage_view_height goes 200dp -> 248dp. The indicator is new
  chrome, so the container grows by its 48dp rather than the chart
  shrinking. This is a visible change beyond the ticket's literal scope;
  it is here because of the touch-target point below.
- TabLayout has no dot mode, so each tab's background is a selector and
  the sliding indicator is suppressed. The oval needs a sized, centred
  layer-list item: a tab background is stretched to fill the tab, which
  ignores a bare shape's <size> and renders an oval as tall as the whole
  row. The active dot differs in both size and colour because several of
  this app's themes resolve colorPrimary to a grey indistinguishable
  from colorOutline (measured on device: #AAAAAA vs #8F9099).

A left-to-right swipe cannot page backwards: that gesture opens the
navigation drawer, which is documented app behaviour ("To view the file
tree and project options, swipe from left to right", shown in the
editor's own onboarding text). InterceptableDrawerLayout's
findScrollingChild starts at index 1 and so never examines DrawerLayout's
content child, which is consistent with that intent. Backward navigation
is therefore by tapping the indicator, which makes the dots a primary
control rather than decoration -- hence real 48dp touch targets,
measured on device at 48x48dp (168x168px at 560dpi), each carrying a
"Metric N of 2" content description.

androidx.viewpager2 is declared explicitly. It was already on the
compile classpath transitively and pinned to the same 1.1.0-beta02 the
version catalog names, so this adds no new dependency; it just stops a
compile-time use depending on another library's graph.

Verified on a Pixel 6 Pro (arm64), v8 debug:
- Both pages render; swipe forward and tap-to-navigate both directions.
- Returning to page 1 shows the complete history for both watched
  processes, including a Gradle Tooling process that started while the
  carousel was open (the rebuild path from the previous commit).
- Font scale 1.0 and 2.0: no clipping, no overlap, status bar clear,
  touch targets unchanged. MPAndroidChart sizes its own text in pixels
  so the chart labels do not grow with font scale -- pre-existing, and
  worth a follow-up for low-vision users.
- Landscape: renders correctly, nothing clipped.
- :app:testV8DebugUnitTest for ui/activities/fragments: 41 tests green.

ADFA-5487

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: let the metrics carousel own horizontal swipes in its own strip

The carousel could only page forwards. A left-to-right swipe opened the
navigation drawer instead, so going back needed a tap on the indicator
dots, which in turn forced them to be 48dp touch targets.

Two mechanisms claim that gesture, and each needs its own answer:

- View-hierarchy interceptors. MetricsCarouselLayout, the new root of
  layout_mem_usage.xml, calls requestDisallowInterceptTouchEvent on its
  ancestors on ACTION_DOWN. That propagates the whole way up, so any
  ancestor ViewGroup is out of the way for the rest of the gesture, and
  only for gestures starting inside this strip.
- The editor's activity-level GestureDetector, run from
  dispatchTouchEvent. It never calls onInterceptTouchEvent, so no
  disallow-intercept can stop it; this was in fact the one opening the
  drawer, confirmed on device. isTouchOnMetricsCarousel excludes the
  carousel's bounds the same way isTouchOnBottomSheetTabs already
  excludes the bottom-sheet tab strip.

The exclusion is gated on swipeReveal.dragProgress > 0. The carousel is
laid out at the top of the reveal even while the content card covers it,
and siblings do not clip each other, so getGlobalVisibleRect reports it
visible either way; without the gate the drawer gesture would have gone
dead over the top of a closed editor.

The vertical reveal drag is unaffected: SwipeRevealLayout only captures
a vertical drag whose touch-down landed in its drag handle (the app
bar), never in this strip.

With swipe working both ways the dots are a status indicator rather than
a control, so they no longer need 48dp targets or accessibility nodes of
their own -- ViewPager2 already reports page position, and each page
carries its own content description. Touches on the indicator are
swallowed so the dots cannot act as tabs, while TabLayoutMediator still
tracks the selected page. The row drops 48dp -> 20dp and, with the panel
kept at 248dp, that space goes to the chart: the plot area grows from
135dp to 187dp. The now-unused metrics_carousel_page string is removed.

Verified on a Pixel 6 Pro (arm64), v8 debug:
- Paging forward and backward by swipe, portrait and landscape.
- Returning to page 1 still shows full history for both watched
  processes.
- Drawer gesture unaffected: still opens from a rightward fling outside
  the carousel while the reveal is open, and from one over the region
  the carousel occupies once the reveal is closed.
- Font scale 1.0 and 2.0: geometry is dp-only and unchanged (pager and
  indicator bounds identical at both), nothing clipped, status bar clear.
- :app:testV8DebugUnitTest for ui/activities/fragments: 41 tests green.

ADFA-5487

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: replace the carousel's dot indicator with a page title

Dots said which page you were on but not what it was. A metrics
carousel is a set of different displays, so naming the current one
carries more information in the same space: "Memory usage" rather than
two dots.

MetricsPage gains a title, so a page names itself and the follow-up
tickets (network chart, plugin-contributed pages) supply one as a
matter of course. A ViewPager2.OnPageChangeCallback drives the label;
it is unregistered alongside the adapter in preDestroy. The callback
does not fire for the page the carousel opens on, so the initial title
is set explicitly.

The title is sp text, unlike the dp-sized dots, so the layout had to
change shape: the title is wrap_content and the pager takes whatever
height is left. At 2x font scale the title grows from 22dp to 35dp and
the chart gives up that space, rather than the label clipping or the
panel changing height. No maxLines or ellipsize -- a long title wraps
and the chart absorbs it, which is the right failure mode for text that
is not disposable.

This drops the TabLayout, the dot selector drawable, its four dimens,
and the touch-swallowing needed to stop dots acting as tabs. The dots'
theme problem goes with them: the active dot needed to differ in both
size and colour because several themes resolve colorPrimary to a grey
indistinguishable from colorOutline.

Trade-off: a title does not show that further pages exist, which dots
did. Worth revisiting if the carousel grows past a handful of pages; at
two, swiping finds the second one and the title then says what it is.

Verified on a Pixel 6 Pro (arm64), v8 debug:
- Titles track the page ("Memory usage", "Code On The Go"); paging both
  directions still works and page 1 still returns with full history.
- Font scale 1.0 and 2.0, measured on a cold start: title 22dp -> 35dp,
  pager 185dp -> 171dp, panel 248dp throughout, nothing clipped.
  EditorActivityKt declares fontScale in configChanges, so it is not
  recreated on a font-scale change -- a warm relaunch reports stale
  geometry and the app must be force-stopped first to measure this.
- :app:testV8DebugUnitTest for ui/activities/fragments: 41 tests green.

ADFA-5487

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: add a UID-level network traffic page to the metrics carousel

Second page of the editor's metrics carousel (ADFA-5487) is now a live
network traffic chart, replacing the brand-mark placeholder.

Accounting is UID-level, as decided on the ticket:
TrafficStats.getUidRxBytes / getUidTxBytes cover every process sharing
the app's UID, so Gradle's downloads are included without any socket
tagging -- the Gradle Tooling and daemon processes share it. There is
deliberately no per-feature breakdown; the only two tagged sockets in
the tree are the local documentation web server and the JDWP listener,
neither of which is interesting here.

The platform counters are cumulative since boot, so NetworkUsageWatcher
records the delta between consecutive samples. Three cases the raw
counters would get wrong:

- The first sample only establishes a baseline and contributes 0.
  Otherwise the chart would open with a spike equal to everything the
  app had transferred since boot.
- A counter that goes backwards (reboot, re-based accounting) records 0
  rather than plotting negative traffic.
- TrafficStats.UNSUPPORTED (-1), which some devices return, is detected
  once and latched, so -1 is never plotted as a byte count.

getUsage() hands out copies rather than the live ring buffers, guarded
by a lock. The renderer reads all 30 entries while the sampler thread
appends, and MemoryUsageWatcher's equivalent has that race today.

Axis, per the ticket's decisions:

- Values are log10(bytes + 1). Traffic spans orders of magnitude -- a
  few hundred bytes of chatter next to a multi-megabyte download -- and
  a linear axis flattens all of it but the largest burst onto the
  baseline. MPAndroidChart has no logarithmic axis.
- The + 1 floors zero, which is the common sample rather than an edge
  case: an idle IDE transfers nothing and log10(0) is negative infinity.
  A zero sample plots at exactly 0.0 and the line stays continuous.
- Units are decimal (1 kB = 1000 B), not binary. This was not in the
  ticket and is a consequence of the log axis: on-device the first cut
  labelled the gridlines 9B / 99B / 999B / 9.8KB, because powers of ten
  divided by 1024 stop looking like decades. Decimal units label them
  0B / 10B / 100B / 1.0kB, and are the convention for throughput.
- Axis labels show 10^value rather than the exact inverse 10^value - 1,
  which would read 9B / 99B / 999B. One byte is not worth the
  confusion, and the legend carries the exact current figure. Zero is
  labelled exactly, since log10(0 + 1) really is 0.

MetricsPage.Image and its layout go with the placeholder, having no
remaining user; ADFA-5490 will define its own extension surface. The
cogo_brand_mark drawable stays -- six other screens use it.

Verified on a Pixel 6 Pro (arm64), v8 debug, over wifi with a real
Gradle sync:
- Both series track real traffic (peaks ~10kB/s against byte-level
  chatter, both legible on the one scale), idle periods sit flat on the
  0B baseline, and the axis reads 0B / 10B / 100B / 1.0kB / 10.0kB.
- Swiping to the memory page and back returns the full 30-sample
  history, so the page is recycling-safe like the memory one.
- Font scale 1.0 and 2.0, measured on a cold start (EditorActivityKt
  declares fontScale in configChanges, so a warm relaunch reports stale
  geometry): title 22dp -> 35dp, pager 185dp -> 171dp, panel 248dp
  throughout, nothing clipped.
- Landscape renders correctly, nothing clipped.
- 16 new tests (7 watcher, 9 renderer); 80 tests green across app
  ui/utils/activities/fragments.

ADFA-5489

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix: label the network axis in whole units and rest zero on the baseline

Two axis problems, one cosmetic and one a real rendering bug.

Labels now read "10 kB" rather than "10.0kB". Gridlines sit on whole
decades (granularity 1), so the mantissa is always exact and the decimal
place carried no information. formatBytes takes the precision as an
argument: none for axis labels, one place for the legend, where the
figure is an arbitrary sample and the decimal does carry information.
A space separates value from unit throughout.

Zero now rests on the baseline. Two causes, both fixed:

- The series were scaled against the wrong axis. LineDataSet defaults to
  axisDependency LEFT, and the labelled axis here is the right one, so
  the line was positioned by the disabled, auto-ranged left axis while
  the labels came from the right. The two only agree while both
  auto-range over the same data; pinning one made them disagree
  visibly -- an idle chart drew its zero line halfway up a plot whose
  baseline was labelled 0 B.
- The range was not pinned. With every sample zero the data range is
  degenerate and the chart pads around it. applyAxisRange now fixes the
  minimum at 0 and the maximum at whole decades above the peak, with a
  floor of three decades so an idle chart keeps a sensible scale
  instead of collapsing onto a single value.

Worth noting for review: the unit tests asserting axisMinimum and
axisMaximum passed throughout, because the axis really was configured
correctly -- the data simply was not drawn against it. Only the device
showed it. There is now a test asserting the axis dependency of both
series, which is the part that was untested.

MemoryUsageChartRenderer has the same LEFT-dependency-with-RIGHT-labels
shape and renders correctly, because it pins neither axis and both
auto-range over the same data. Left alone.

Verified on a Pixel 6 Pro (arm64), v8 debug:
- Idle: both series rest exactly on the 0 B baseline, axis reads
  0 B / 10 B / 100 B / 1 kB.
- Under a Gradle sync: axis grows to 10 kB, peaks and zero-traffic
  troughs both legible, legend reads "212 B/s".
- 49 tests green across app ui/utils, including four new ones covering
  the axis range, its growth across both series, whole-unit labels, and
  the axis dependency.

ADFA-5489

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix: honour MemoryUsageWatcher's configured sampling interval

The sampling loop called a hardcoded delay(1000), ignoring the
updateInterval constructor parameter it was given. Passing a different
interval changed nothing, so the sample rate was fixed at one second
whatever a caller asked for. NetworkUsageWatcher (ADFA-5489) uses its
interval correctly, so the two watchers disagreed.

This is the "sample time is fixed" of ADFA-5486, present in the code and
not only in the UI. Making the interval configurable from settings is
the rest of that ticket; this makes the existing parameter mean
something first.

Two supporting changes, both needed to test the loop at all:

- The dispatchers are injectable, defaulting to the single-thread
  context and Dispatchers.Main.immediate as before. Tests drive the loop
  on a TestDispatcher and advance virtual time, so the regression test
  is deterministic rather than a wall-clock race. A first attempt that
  slept on the real clock hung the test executor.
- readUsages() returns before the ActivityManager lookup when no process
  is being watched. Behaviour-preserving -- it went on to iterate zero
  pids -- and it keeps an idle watcher off BaseApplication, which a unit
  test does not have.

Verified the tests fail without the fix: with delay(1000) restored, "the
sampling rate follows the configured interval" reports 1 sample where it
expects at least 9, for exactly the reason it is named for. The
longer-interval test passes either way by construction; it guards the
proportionality, not the bug.

Verified: :app:testV8DebugUnitTest, 51 tests green across app ui/utils.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* refactor: extract MetricsChartRenderer, shared by both carousel charts

ADFA-5489 gave the metrics carousel a second chart, and with it a second
copy of the chart setup: the two renderers had a byte-identical
configure() apart from the value formatter, and a byte-identical block
in rebuild() applying theme colours and redrawing.

ADFA-5486 adds x-axis labels, zoom, event annotations and snapshot
export to "the line chart", written when there was only one. All four
belong on both charts, and duplicated setup is how they end up on one.
This puts the common behaviour in one place before that work starts.

MetricsChartRenderer holds the attach/detach lifecycle -- including
detachIfAttached, which a recycling carousel page needs -- the shared
axis and gesture configuration, and the data/redraw helpers. Subclasses
override configure() to add what is theirs (the memory chart's MB
formatter; the network chart's byte formatter and per-decade
granularity) and call through.

Behaviour-neutral: no configuration value changed, only where it lives.
The existing renderer tests are the evidence, and both charts were
compared on device against the previous build.

Verified: :app:testV8DebugUnitTest, 51 tests green across app ui/utils;
both carousel pages rendered on a Pixel 6 Pro (arm64, v8 debug),
including the network chart under a live Gradle sync.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: retain an hour of samples, in a ViewModel, shown as a moving window

Retention goes from 30 samples to 3600 -- an hour at the current one
second interval -- so that zoom, pan and event annotations have
something to work against. Against 30 samples they are close to
meaningless.

Three parts, each a consequence of the first:

History moves into MetricsViewModel. The watchers were fields on the
editor activity and survived rotation only because EditorActivityKt
happens to declare orientation in its configChanges. Drop that flag, or
add a screen that does not declare it, and an hour of history would
vanish silently. An activity-scoped ViewModel makes survival a property
of the lifecycle rather than a manifest coincidence. It does not survive
process death; that is ADFA-5494.

The chart shows a window of 60 samples rather than all 3600. Holding an
hour is cheap -- about 29KB of longs per series -- but drawing 3600
points per series into a 200dp strip is not, and it would be illegible
anyway. MPAndroidChart clips drawing to the visible x range, so a window
keeps the cost independent of how much is retained. This is also the
shape the zoom feature needs, arrived at from the other direction.

The x axis is labelled by age. Sample indices were already meaningless
and would now run to 3599. This pulls forward part of the ticket's
x-axis-labels step, because 3600 samples made the old labels actively
worse rather than merely uninformative.

Two bugs found on device that no unit test would have caught:

- A bound callable reference evaluates its receiver where it is written.
  Passing memoryUsageWatcher::getMemoryUsages from a field initializer
  therefore reached the ViewModel during the activity constructor, which
  throws "You can't request ViewModel before onCreate call" and made the
  editor unlaunchable. The providers are lambdas now, so the watcher is
  resolved per call.
- The visible x range is held as a scale factor, so a layout change left
  the window pointing at a different part of the history: after a
  rotation the chart showed samples from half an hour earlier, with the
  axis reading -1979s. The window is re-applied on every redraw rather
  than only when data is set.

Verified on a Pixel 6 Pro (arm64), v8 debug:
- Both charts show a rolling 60-second window, x axis reading -59s to
  now, over an hour-deep buffer.
- History survives rotation: the same traffic burst was still on screen
  after a portrait/landscape round trip, correctly aged from -14s to
  -29s, with sampling continuous across the change.
- Landscape re-verified after the viewport fix; no crashes throughout.
- 66 tests green across app ui/utils/activities.

Known and deliberate: sampling still stops in onPause, so a backgrounded
editor leaves a gap that the evenly-spaced x axis does not represent.
Raised on the ticket.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix: make the x axis labels visible, and sample while backgrounded

Two things, both from looking at the device rather than the tests.

The x axis labels were never missing. MPAndroidChart defaults every
component's text to Color.BLACK. setData gave the y axis and the legend
a themed colour and nobody ever gave one to the x axis, so its labels
have been drawn black on a near-black surface for as long as the chart
has existed. Brightening a screenshot 3.2x shows them sitting there
perfectly well formed. That is the "the line chart x axis has no labels"
of ADFA-5486: not absent, invisible. One line fixes it.

Sampling now continues while the editor is backgrounded. It used to stop
in onPause, which was harmless at 30 samples and is not at 3600: the x
axis assumes samples are evenly spaced, so any spell in the background
made it misreport how old everything to the left of the gap was. Only
the listeners are dropped on pause, so nothing redraws a chart nobody is
looking at, and sampling itself now lives as long as MetricsViewModel.
onResume rebuilds both charts rather than waiting a tick, and only
starts a watcher that is not already running -- otherwise every resume
logged a spurious "already being watched" warning.

This also makes the chart answer a question it could not before: what
memory did while you were not looking. Verified by backgrounding the
editor for 25 seconds -- the chart came back showing the drop as the app
went away, the plateau while it was gone, and the rise on return, all
recorded.

Battery: one /proc read and one TrafficStats read per second while
backgrounded. Modest, and the platform freezes cached processes anyway,
which stops it for free.

Verified on a Pixel 6 Pro (arm64), v8 debug:
- x axis reads -59s / -44s / -29s / -14s in the same colour as the y
  axis labels.
- Background sampling as described; no gap in the history.
- No "already being watched" warnings in logcat; no crashes.
- 66 tests green across app ui/utils/activities.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: raise retention to 10000 samples and add the sampling-rate policy

Groundwork for the tap-on-x-axis rate dialog, which the ticket
description now specifies (0.1s to 60s). The dialog itself is not built
yet; this is the machinery it will drive.

Retention goes from 3600 to 10000 samples. With the rate variable, a
sample count no longer means a fixed span: 10000 covers most of three
hours at one second and about seventeen minutes at the 0.1s floor. 80KB
of longs per series, and drawing cost is unchanged because the chart
shows a window rather than the whole buffer.

The sampling interval is now settable, and changing it clears the
history. The chart reads a sample's age from its position, which assumes
every sample is the same age apart; a buffer holding samples taken at
two rates would silently misdate all the older ones. The network watcher
also drops its cumulative baseline, otherwise the first sample after a
change would report every byte since the previous one as a single delta
-- a spike at exactly the moment the user changed the rate.

MetricsSamplingRates holds the floors: 0.1s on 64-bit hardware, 0.5s on
32-bit. Sampling costs a Debug.getMemoryInfo call per watched process
plus two TrafficStats reads every interval, and ten times a second on a
weak device is enough to distort what the chart is measuring.

Rates a device cannot use are still listed, marked unavailable, rather
than hidden -- Rate.isAvailable is what the chooser should grey out.
A chooser that silently omitted them would leave the user assuming the
IDE cannot sample faster, rather than seeing that their hardware is what
costs them the two fastest rates.

The floor is keyed on the device's architecture, not the build flavour:
a 32-bit build of the IDE running on a 64-bit phone is still running on
hardware that can afford the faster rate.

Verified on a Pixel 6 Pro (arm64), v8 debug: both charts render
unchanged at the higher retention, no crashes. 60 tests green across app
ui/utils, 9 of them new.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* refactor: extract MetricsCarouselController ahead of undocking

The carousel's pages, renderers, page-change callback and watcher
listeners were spread across BaseEditorActivity. Undocking (ADFA-5486)
needs the same carousel built against a floating window's context, so
running one is now a thing an object does rather than something an
activity is.

The activity keeps what is genuinely its own: the status-bar inset on
the pager, when to start and stop sampling, and which colour each
watched process is drawn in -- the last passed in as a lambda, because
the process names it keys on belong to the activity.

Binding also takes over the watcher listeners, which is what makes the
controller the single owner of "a carousel that is being looked at".
onPause unbinds and onResume rebinds; sampling is untouched by either,
so the history stays continuous.

Worth recording for the undocking work: only one carousel can be live at
a time. MemoryUsageWatcher and NetworkUsageWatcher each hold a single
listener, not a list, so a second carousel would silently take the
updates from the first. Undocking therefore has to move the carousel out
of the editor rather than copy it into the window -- which matches how
an editor file tab already undocks, leaving the tab row.

Behaviour-neutral. Verified on a Pixel 6 Pro (arm64), v8 debug: both
pages render, paging works, and backgrounding for 15 seconds and
returning shows continuous history across the gap, exercising the
unbind/rebind path. 75 tests green across app ui/utils/activities.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: undock the metrics carousel into a floating window

A two-finger tap on the carousel floats it over other apps, and the
editor shows "Metrics are in a floating window. Tap to bring them back."
in the space it vacates. Tapping that message, or the window's own dock
control, brings it back.

Undocking moves the carousel rather than copying it. MemoryUsageWatcher
and NetworkUsageWatcher hold a single listener each, so two live
carousels would mean the second silently taking the first one's updates.
MetricsCarouselDockableContent therefore rebinds the editor's own
MetricsCarouselController into the window, and the editor shows the
message instead. That also matches how an editor file tab undocks,
leaving the tab row. The history is untouched by the move: the watchers
own it, so the carousel is redrawn in full wherever it binds.

Without the message the reveal would open on an empty strip, which reads
as broken, and a window dragged off screen would leave no way back.

The gesture is recognised in dispatchTouchEvent, not
onInterceptTouchEvent. ViewPager2's RecyclerView calls
requestDisallowInterceptTouchEvent on its parents the moment a second
pointer lands, and a ViewGroup only calls onInterceptTouchEvent while
that flag is clear -- so the first version saw the two fingers arrive
and never saw them leave. It fired on nothing. dispatchTouchEvent is
delivered first and the flag does not affect it.

The unit tests did not catch that, because they called
onInterceptTouchEvent directly: they proved the recogniser's logic and
not that the framework would ever call it. They now drive
dispatchTouchEvent, which is what actually happens. Same failure as the
chart axis earlier in this ticket -- a green test over a wire that was
never connected.

Also generalises the project-close teardown. closeAll released resources
only for EditorPanelDockableContent, so any other content type would be
removed from DockingManager without being told; it now gets
onDestroyView, which is how the carousel unbinds its controller.

Verified on a Pixel 6 Pro (arm64), v8 debug, the two-finger taps done by
hand because adb cannot inject multi-touch and sendevent needs root:
- Two-finger tap undocks; the window shows the carousel with its chrome
  and the editor shows the message.
- Tapping the message re-docks, and the chart returns with its history
  intact across the float.
- FloatingTabService starts on undock and stops on re-dock; no leaked
  service, no crashes.
- 508 tests green across the app module, 5 of them new for the gesture.

Known gap: the two-finger tap cannot be exercised in CI for the same
reason it could not be scripted here.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix: make the sampling loop stoppable, restartable and crash-proof

Three defects raised in review of ADFA-5487/5489, all in the same few
lines and all present in both watchers.

stopWatching() could not stop the sampler. The loop was launched with
`launch(context = SupervisorJob() + dispatcher)`, which gives the
coroutine its own parent job, so the watcher's scope could not cancel
it: it ran on until it next observed the `watching` flag, and it spends
almost all of its time asleep in `delay(updateInterval)`. Stop and start
inside that window and the old loop woke up, saw the flag set again, and
carried on beside the new one -- two samplers writing history and
notifying the chart. The window is as wide as the interval, which
ADFA-5486 made configurable up to sixty seconds. The job is now stored
and cancelled.

An exception ended sampling permanently. A throw anywhere in the body
killed the coroutine while `watching` stayed true, so every later
startWatching() was refused as "already watching" and the chart silently
stopped updating for the rest of the session. A misbehaving listener was
enough. The body is guarded now: a sample is worth losing, the loop is
not. CancellationException is rethrown so cancellation still works.

The dispatcher was never closed. `newSingleThreadContext` holds a thread
until closed, and nothing closed it. close() is separate from
stopWatching() because the watcher is stopped and restarted across the
editor's lifecycle; only the terminal teardown should give up the
thread. MetricsViewModel.onCleared calls it.

startWatching() also uses compareAndSet rather than a check followed by
a set, so two callers cannot both pass the guard.

Tests: 5 new lifecycle tests. Verified they fail without the fix, though
the first one fails by hanging rather than by asserting -- with the loop
unstoppable, runTest never drains the scheduler. That is the bug seen
from the inside, and it is why each test now closes its watcher.

Verified on a Pixel 6 Pro (arm64), v8 debug: chart samples continuously
across a background/foreground cycle, no crashes, nothing logged from
the new failure guard. 70 tests green across app ui/utils.

Addresses CodeRabbit findings on #1784.

ADFA-5486

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: annotate the metrics charts with Gradle task events

Significant events are Gradle task starts and stops, drawn as dashed
vertical markers labelled with the task name.

Gradle emits those far faster than a chart can show them -- an
incremental build blasts through dozens of up-to-date tasks in a second
or two -- so MetricsAnnotationStore throttles to at most one every five
seconds and keeps the first of each quiet period, since the interesting
moment is when work began rather than an arbitrary one from the middle
of a burst.

Annotations are stored by wall-clock time, not by sample position. The
charts hold a ring buffer whose contents shift under them, so a stored
index would drift; the renderer converts a timestamp to an x position
from its age at draw time, and anything older than the buffer holds
falls outside the axis. A marker therefore travels left with the data
and leaves the visible window, which is what it should do.

The events already reached EditorBuildEventListener.onProgressEvent for
the status line, so this needed no new plumbing -- only a second use of
the same TaskStartEvent, plus TaskFinishEvent.

Worth recording, because it would have shipped silently broken:
lastRecordedAt started at Long.MIN_VALUE, so `now - lastRecordedAt`
overflowed to a negative gap on the very first call. That reads as
"inside the throttle window", so the store swallowed every annotation
for its entire life and nothing anywhere reported an error. All seven
tests caught it on their first run. It is nullable now.

Verified on a Pixel 6 Pro (arm64), v8 debug: a project sync records
nothing, correctly -- a sync configures and emits no task events -- and
a build draws a marker at :app:preBuild, confirmed on screen. The rest
of that build's tasks completed inside the five-second window and were
collapsed into that one marker, which is the throttle working as
specified.

7 new tests; 77 green across app ui/utils.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: export a chart snapshot as a shareable image

Long-pressing the chart title writes the visible chart to a PNG and
hands it to the system share sheet, so it can go into a ticket, a chat
or a file.

Snapshot means an image of the chart, as decided on the ticket. The
gestures over the chart itself are all spoken for -- paging, panning a
zoomed chart, and the two-finger tap that undocks -- so the title is the
target: an unambiguous one that behaves the same whether the carousel is
docked or floating.

Images go to a directory under the cache, so the platform can reclaim
them, and each export clears the previous one. This is a scratch space
for handing a single image to another app, not a gallery; the sharing
intent grants the receiving app access before the next export matters.

Chart titles are translated, so the filename is derived rather than
copied: lowercased, everything outside a-z0-9 collapsed to hyphens, and
falling back to "metrics" if nothing usable is left.

Verified on a Pixel 6 Pro (arm64), v8 debug: long-pressing the title
raised the share sheet showing a preview of the real chart, and left
memory-usage-20260905-103613.png (37KB) in the cache directory.

5 new tests; 82 green across app ui/utils.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: choose the sampling rate by tapping the x axis

A tap on the x axis opens a chooser offering every rate from 0.1s to
60s, as the ticket specifies. Picking one applies it to both watchers
and discards the history, because a buffer holding samples taken at two
rates would misdate the older ones.

Rates the device cannot use are listed and greyed rather than hidden,
so the user can see that their hardware is what costs them the two
fastest rates instead of assuming the IDE cannot sample faster. On a
64-bit device all nine are selectable; on 32-bit the 0.1s and 0.2s
entries read "needs a 64-bit device" and do nothing.

The tap is recognised through the chart's own gesture listener rather
than a view: the axis is drawn by MPAndroidChart, so there is nothing to
attach a click listener to, and only the chart knows where it put the
axis. A tap above viewPortHandler.contentTop landed on it.

Two bugs found on the device while doing this:

The dialog first appeared with no list at all. An AlertDialog shows
either a message or a list, never both, and the message silently wins --
so the explanatory line had swallowed the nine rates. The explanation
lives on the greyed entries instead.

The x axis kept labelling with the old interval after a rate change:
ElapsedTimeFormatter captured sampleIntervalMillis at construction, so
at 5s per sample it still read -54s where the leftmost sample was really
295 seconds old. Annotation positioning shared the flaw. Both take a
provider now and read the live value. I had flagged this risk when
making the interval settable and then did not carry it through.

Verified on a Pixel 6 Pro (arm64), v8 debug: the chooser opens from an
axis tap with the current rate ticked, selecting a slower rate clears
the history and refills at the new rate, and the gridlines re-space to
match.

82 tests green across app ui/utils.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: trigger the chart snapshot from a camera button

Replaces the long-press on the chart title with a camera button in the
graph's bottom-right corner, at your request.

The long-press worked but advertised nothing: a user had no way to
discover that the title did anything. A visible control does not have
that problem, and it costs no gesture -- every gesture over the chart is
already taken by paging, the two-finger tap that undocks, pinch to zoom,
and the tap on the x axis for the sampling rate.

The icon is small, as asked, and sits as low and as far right as the
graph area allows. The button around it keeps a 40dp touch target, since
the visual size of a control and its touch target need not match, and a
24dp target would be hard to hit.

Verified on a Pixel 6 Pro (arm64), v8 debug: the button sits in the
corner of the plot, and tapping it raises the share sheet showing the
real chart, leaving memory-usage-20260905-105005.png in the cache.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: pinch to zoom the chart, with the carousel swipe kept below the axis

The time axis zooms and a zoomed chart pans, without taking the swipe
that pages the carousel.

The x axis moves to the bottom of the plot. Your split -- carousel swipe
below the axis, pan above it -- assumed the conventional position, and
ours was at the top, where "above the axis" is a sliver against the
status bar. At the bottom the split describes real regions: the plot,
and the strip of axis labels, legend and title beneath it.

Ownership of a horizontal drag is settled once, on the way down, before
either the pager or the chart has seen a move: the pager's touch paging
is switched off for the gesture when the drag starts inside the plot of
a zoomed chart, which lets the drag through to pan it. Everywhere else
the carousel keeps the swipe -- the strip below the axis always, and the
whole chart while it is at rest, since there is nothing to pan to.

Only the time axis scales. Zooming the value axis on a memory or
throughput chart just makes the numbers lie about their own scale.

Two things that would otherwise make zoom useless: the auto-follow
window no longer re-centres while zoomed, which would have dragged the
user back to the newest samples once a second; and switching carousel
page resets the zoom, so a page left magnified does not go on claiming
horizontal drags when it comes back.

Not verified on hardware. A pinch cannot be injected on an unrooted
device -- adb input has no multi-touch and sendevent needs root -- which
is the same limit the two-finger tap hit. The axis position and the
absence of regressions are verified; the pinch itself needs a hand.

82 tests green across app ui/utils.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix: restore the carousel swipe and the auto-follow window; add paging arrows

Two of the three problems reported from the device turned out to be one
bug.

Showing a 60-sample window of a 10000-sample buffer *is* a zoom as far
as MPAndroidChart is concerned: scaleX sits around 166 at rest. So
testing `scaleX > 1f` for "has the user zoomed" was always true, with
two consequences. The auto-follow window stopped re-centring after the
first draw, which is why a floating window drifted to around -5000s. And
the chart claimed every horizontal drag, which is why moving between
carousel pages was so hard -- the swipe was being taken to pan a chart
nobody had zoomed.

Zoom is now recorded from the scale gesture itself rather than inferred
from the viewport, which cannot be confused by the window we set.

Paging arrows either side of the chart title. Swiping still works, but
it competes with panning a zoomed chart and with the editor's drawer
gesture, and losing that race intermittently is worse than not having
the gesture at all. The arrow for an end of the carousel is dimmed and
disabled.

Keyboard in the floating window: nothing in the carousel is typed into,
so nothing in it should take focus. A focusable child makes an overlay
window focusable, and the soft keyboard then opens over the chart on
every touch. The content blocks descendant focus, and a touch also
dismisses any keyboard already showing.

Verified on a Pixel 6 Pro (arm64), v8 debug: the arrows move between
pages and dim at each end, and the axis, window and legend are unchanged
otherwise. The keyboard fix and the floating-window drift need the
window open to confirm.

82 tests green across app ui/utils.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix: tint the carousel arrows so they are visible on a dark chart

The shared arrow drawables carry a hardcoded android:tint="#000000", so
the paging arrows were drawn black on the near-black chart surface and
could not be seen at all.

This is the same failure as the x axis labels earlier in this ticket,
which were invisible for the same reason -- MPAndroidChart defaults its
text to Color.BLACK -- and it happened again because these icons were
reused without checking what colour they came with. Anything drawn on
this surface needs its colour asserted at the usage site rather than
assumed.

Tinted at the usage site rather than by editing the shared drawables,
which are used elsewhere on light backgrounds.

Verified on a Pixel 6 Pro (arm64), v8 debug: both arrows legible, the
one at the end of the carousel dimmed.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat: page the carousel only with the arrows

Swiping in the graph area no longer changes page. The arrows either side
of the title are the only way.

This removes a three-way contention rather than arbitrating it. A
horizontal drag in the plot was wanted by the carousel, by a zoomed
chart wanting to pan, and by the editor's drawer gesture; deciding
between them per gesture worked, but losing the race intermittently made
the carousel feel unreliable, and no amount of tuning makes an ambiguous
gesture feel deliberate.

With touch paging off, a horizontal drag in the plot is unambiguously a
pan, and paging is a plain control that cannot be misread. The gesture
arbitration goes with it: the router in MetricsCarouselLayout, the
paging-enabled callback, and handlesHorizontalDragAt on the renderer are
all deleted rather than left switched off.

What stays: the layout still asks its ancestors not to intercept, so a
horizontal drag in this strip reaches the chart to pan with instead of
opening the drawer, and the editor's fling detector still excludes the
carousel's bounds.

The x axis stays at the bottom. It moved there so the strip beneath it
could be reserved for the carousel swipe, which no longer exists, but
the bottom is the conventional place for a time axis and moving it back
would be churn.

Verified on a Pixel 6 Pro (arm64), v8 debug: a swipe across the plot
leaves the title on "Memory usage", and the next arrow moves it to
"Network traffic".

82 tests green across app ui/utils.

ADFA-5486

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat(metrics): add a temperature and power page to the carousel (ADFA-5499)

A third carousel page charts battery temperature against instantaneous power
draw, with thermal throttling shaded behind the plot and the battery level
shown in the corner.

Design decisions, and what was rejected:

- Instantaneous power, not cumulative. A running total only ever rises and
  says nothing about which piece of work cost anything; instantaneous draw
  lines up with the spikes on the memory and network pages.
- Battery readings only. The per-zone CPU, GPU and skin temperatures need
  android.permission.DEVICE_POWER, which is prot=signature|role|module -- it
  cannot be granted to an installed app, so there is no prompt to defer and
  no fallback worth attempting. PowerSource is an interface so a privileged
  build can supply better readings without the chart changing.
- Throttling is shaded, not plotted. The platform reports an ordinal level,
  not a temperature, so plotting it against degrees would invent a scale.
  Alpha rises with severity so the bands read as a gradient of concern.
- Battery level is a readout, not a series: it moves about a percent every
  few minutes, so over the chart's window a line would be flat, spending an
  axis on a constant. Hidden while charging, when a rising level would
  contradict a chart about power being spent. Charging periods are not
  shaded.
- Two value axes, the only page with them. Degrees and milliwatts share no
  unit, so each series declares its axis; a series left on the default would
  be drawn against labels that do not describe it.
- Power is plotted as a magnitude. The battery current reverses while
  charging, and a line dipping below zero would read as negative power spent.

Two defects found on-device, both invisible to passing unit tests -- the same
class of failure as the black-on-black axis labels and the black-tinted arrows
earlier in this stack:

- Shading never reached the screen. setDrawGridBackground(true) fills the plot
  opaquely inside super.onDraw, so spans painted before it were covered.
  SafeLineChart now overrides drawGridBackground and paints the spans straight
  after that fill, which also puts them under the grid lines and the data.
- A single-sample throttle had zero width. Spans ran centre to centre, so one
  sample mapped to one pixel column and two adjacent runs left a sample-wide
  gap. Each span now covers its samples' full cells.

Also wired up two things that were built but unreachable: the power page's
x-axis tap now opens the sampling-rate chooser like the other pages, and
batteryReadout() now has a view to write to.

Verified on a Pixel 6 Pro (arm64) with `cmd thermalservice override-status`
stepped through levels 1, 3 and 6 and `dumpsys battery unplug`: three bands
appear, deepen with severity, abut without gaps, and stop when the override
clears. Checked at font scale 1.0 and 2.0 -- the title, arrows and battery
readout all grow without clipping. The chart's own axis and legend text is
drawn by MPAndroidChart in dp and does not scale, which is a pre-existing
limitation of the library recorded under ADFA-5486, not new here.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* feat(metrics): colour the throttle bands, label power in watts, stagger annotations

Four changes to the temperature and power page (ADFA-5499) and one to the
annotations shared by every page (ADFA-5486).

Throttle shading is now hue-coded rather than one colour at six depths:
green, cyan, yellow, orange, rust, red for levels 1 to 6, at one fixed alpha.
Level 0 and an unreadable level stay unshaded. Ranking seven ordinals by depth
of a single colour asks the eye to compare shades that are never side by side;
the bands are separated in time, so distinct hues stay tellable apart wherever
on the chart they fall. The source is unchanged: PowerManager.getCurrentThermalStatus()
on API 29+, with ThermalInfo behind it for API 28, which minSdk still admits.

The power axis is labelled in whole watts. A build peaks in single-digit watts,
so milliwatt labels spent three characters each on trailing zeros. Granularity
is pinned to 1 W as well: left to choose its own spacing the axis puts gridlines
a fraction of a watt apart on an idle device, and rounding those to whole watts
prints the same label several times over. The legend keeps finer units, falling
back to milliwatts below a watt, where "0W" would lose the only value it exists
to show.

Each value axis takes the colour of the line it describes -- orange for
temperature on the left, blue for power on the right. With two axes carrying
unrelated units, colour is what says which reads which.

That last one needed a hook. setData repaints both axes in the surface's text
colour on every redraw, so anything a subclass set in configure was overwritten
within a frame; it now calls an open styleValueAxes, which the power page
overrides. The test caught this -- the same shape as the two defects in the
previous commit, and this time it was caught before the device.

Annotation labels are staggered across eight rows, cycling. Gradle fires tasks
in bursts, so several markers land within a few pixels of each other and their
labels, all drawn on one row, overwrote each other into an unreadable smear.
The row comes from a new Annotation.sequence, counted from the first annotation
of the session, rather than from a position in the visible list: that list
shifts as older entries age out, so a label would hop rows while merely sitting
still.

Nothing covered the drawing of annotations before this, only the store behind
them, which is how the smear came to ship. MetricsAnnotationRenderingTest now
covers it; its three stagger tests were confirmed to fail with the offset held
constant, and the row-stability test to fail when the row is taken from the
visible list.

Verified on a Pixel 6 Pro against a newly created Compose Activity project, so
the Gradle run was long and task-dense: three annotations drawn on three
different rows, the right axis reading 0W through 6W, the left axis orange and
the right blue, and all six throttle hues distinct under
`cmd thermalservice override-status`.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix(metrics): put the sampling-rate tap on the edge the x axis is drawn on (ADFA-5486)

The chooser was reachable only from a blank strip above the plot, at the
opposite end of the chart from the axis labels the gesture is named for. The
hit test compared against contentTop while the axis is positioned BOTTOM, so
tapping the labels did nothing and the rate could not be changed by anyone who
did not already know where the hidden band was.

The strip under the plot had been left alone for the carousel swipe. Paging is
by the arrows now, so it is free, and the tap moves there.

The two have to agree, and nothing said so: a comment on each site now points
at the other.

MetricsChartAxisTapTest covers all three bands. Confirmed to fail against the
old hit test in both directions -- the tap below the plot not registering, and
the tap above it still registering -- so it pins the edge rather than merely
the existence of the gesture. A guard test asserts the chart was laid out
first, without which every coordinate sits on the same edge and the others
would pass vacuously.

Verified on a Pixel 6 Pro: tapping the "-54s" labels opens the chooser,
tapping the band above the plot does nothing, and picking "Every 5s" relabels
the axis to -270s and clears the history as intended.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix(metrics): address four review findings on the carousel (ADFA-5486)

Four defects found by review -- one mine, three CodeRabbit's -- fixed in the PR
that owns them rather than in a later one in the stack.

An activity was reachable from the floating window. The memory chart's line
colour came from `::getMemUsageLineColorFor`, a bound reference to a
BaseEditorActivity method, stored in MetricsCarouselController, which is handed
to MetricsCarouselDockableContent and held by the floating-window host. Across
a recreation while undocked -- a rotation is enough -- that pinned the old
activity. The function is pure: process name in, colour constant out. It moves
to the companion, so the reference binds a singleton instead.

The snapshot did disk I/O on the main thread. `MetricsSnapshot.write` lists a
directory, deletes its contents, encodes a full-chart PNG and writes it, and
the camera button called it inside the click listener. The bitmap still has to
be taken on the UI thread, but the encode and the write now run on
Dispatchers.IO. The controller gained a scope for that, and a close() so a
snapshot in flight is cancelled with the editor.

Getting that wrong once is worth recording: moving the *share* onto the
application context along with the write crashed on the first tap, because
startActivity throws from a context with no task unless it is given
FLAG_ACTIVITY_NEW_TASK. Only the write wanted the long-lived context. The share
re-reads the host binding instead of capturing it, because the export is no
longer instantaneous and the carousel can be docked or undocked while the file
is written.

MemoryUsageWatcher had no lock on its history. Its two siblings both guard
their ring buffers and hand out copies; this one did neither, and ADFA-5486
added a clearHistory() that the rate dialog calls from the UI thread while the
sampler is appending. clear() is a fill plus a shift reset, the append is a
write plus a shift, and interleaved they leave the shift pointing at data that
is no longer there. Now serialised on a lock, matching the other two.

A non-positive sampling interval could spin the sampler. delay() does not
suspend for one, so the loop would pin a core for as long as the editor is
open. MetricsSamplingRates already had a coerce function that nothing ever
called; it gains a device-independent sibling for the watchers to guard
themselves with, applied in both the constructor and the setter -- the
constructor initialiser bypasses the setter, so it needs its own.

The two interval tests were confirmed to fail without the clamp. The lock has
no test: a data race has no deterministic failing case, and asserting on one
would pin the scheduler rather than the behaviour.

Verified on a Pixel 6 Pro: the memory chart still draws its lines in the right
colours, and the camera button produces a share sheet with the chart image and
no crash, with the disk work off the main thread.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* docs(metrics): correct the sign contract on the battery current (ADFA-5499)

`BATTERY_PROPERTY_CURRENT_NOW` is positive for current entering the battery --
charging -- and negative for current leaving it. The KDoc on
`PowerReading.powerMicroWatts` claimed the opposite, and a test name repeated
the claim.

No behaviour changes, and deliberately so. CodeRabbit's suggestion was to
negate the reading to match the doc; that would make the stored value disagree
with the platform it came from, which is the wrong half to move. Nothing
consumes the sign: the renderer plots the magnitude, both because a line
dipping below zero reads as negative power spent and because not every OEM
signs this property the way the documentation says. That second reason is now
written down where it belongs, next to the reading.

Confirmed against the device the feature was built on: current_now reads
positive while charging.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix(metrics): put the sampling-rate tap on the edge the x axis is drawn on (ADFA-5486)

The chooser was reachable only from a blank strip above the plot, at the
opposite end of the chart from the axis labels the gesture is named for. The
hit test compared against contentTop while the axis is positioned BOTTOM, so
tapping the labels did nothing and the rate could not be changed by anyone who
did not already know where the hidden band was.

The strip under the plot had been left alone for the carousel swipe. Paging is
by the arrows now, so it is free, and the tap moves there.

The two have to agree, and nothing said so: a comment on each site now points
at the other.

MetricsChartAxisTapTest covers all three bands. Confirmed to fail against the
old hit test in both directions -- the tap below the plot not registering, and
the tap above it still registering -- so it pins the edge rather than merely
the existence of the gesture. A guard test asserts the chart was laid out
first, without which every coordinate sits on the same edge and the others
would pass vacuously.

Verified on a Pixel 6 Pro: tapping the "-54s" labels opens the chooser,
tapping the band above the plot does nothing, and picking "Every 5s" relabels
the axis to -270s and clears the history as intended.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QeW3M24yD6HNhEnbuNW7Hz

* fix(metrics): make the network sampling loop stoppable and crash-proof (ADFA-5489)

CodeRabbit raised three Major findings against this watcher. They were fixed,
but on #1785 -- a later PR in the stack than the one that ships the bug. This
PR is already approved and ahead of that one, so on its own it still carried
all three. Moving the fix to where the defect lives.

The scope had no parent Job and startWatching() supplied its own SupervisorJob
per launch, so nothing the scope did could cancel the sampler. stopWatching()
only lowered a flag the loop checks once per interval, and the loop spends
nearly all its time in delay() -- up to 60s once ADFA-5486 makes the rate
configurable. A stop and start inside that window left two loops appending to
one buffer, splitting each delta between them. The scope now has a parent job,
the launch is stored, and stopWatching() cancels it.

Nothing caught exceptions inside the loop. An exception -- a misbehaving
listener is enough -- ended the coroutine while `watching` stayed true, so
every later startWatching() was refused as "already watching" and sampling was
dead for the rest of the session. The body is wrapped, and CancellationException
is rethrown so structured cancellation still works.

The dedicated sampling thread was never released. close() is separate from
stopWatching() on purpose: the editor stops and restarts the watcher across its
lifecycle, and only the terminal teardown should give up the thread that
newSingleThreadContext keeps alive. The activity's destroy path calls it.

startWatching() now guards with compareAndSet rather than a read followed by a
write, so two callers racing cannot each start a sampler.

The watcher takes its dispa…